Dynamic workflow approvals

ABSTRACT

A dynamic approval system, capable of integration with enterprise software systems, where approval requests are generated from within application programs and processed using one or more dynamic approval rules comprising discrete rule steps and step criteria. For each approval request, only those rule steps applicable to the requestor and type of request are processed. Individual rule steps may be reordered, added or skipped, as appropriate, during an approval process. Typical rule steps include at least one request for approval or review. The party receiving the request may be a specific individual, a person holding a specific position, or a person having a relative relationship, such as supervisor, with the requestor.

CROSS-REFERENCES TO RELATED APPLICATIONS

This Application is a divisional of U.S. patent application Ser. No.10/187,351, filed Jun. 28, 2002 and entitled “DYNAMIC WORKFLOWAPPROVALS,” which is herein incorporated by reference for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention is in the field of enterprise software and morespecifically in the field of approval management software.

2. Description of the Prior Art

Businesses use systematic approval methods to control decisions madewithin their organizations. These methods can be multi-step processesrequiring authorization by multiple parties and therefore requiringsignificant time. Approvals are required in almost every activity of alarge business. For example, purchasing requires approval for theexpenditure of funds, human resources requires approval for hiring, andengineering requires design approvals.

In addition to requiring significant time, prior art approval methodsare plagued with other problems. For example, it can be difficult totrack approvals as they move through an organization and approvalprocesses must be rigid to assure that all proper approvals areobtained. Software systems designed to assist in approval processestypically require that each approval scheme be specifically programmedand are thus inflexible. When requirements or personnel change, theseinflexible systems require that computer code be rewritten accordingly.Software generally designed for approval tracking is also typicallypoorly integrated with enterprise software designed to accomplish tasksthat need approval. For example, many organizations use one set ofsoftware to place purchase orders and a separate set of software togenerate approvals. The use of separate systems contributes to the timeand effort expended on these tasks and increases the probability oferrors or unauthorized activities.

BRIEF SUMMARY OF THE INVENTION

A system for processing an approval request, some embodiments of thesystem comprising an approval interface configured for an approver toapprove or deny the approval request and an approval rule processorconfigured to a) load at least one dynamic approval rule including oneor more rule steps characterized by rule step criteria, b) determine ifat least one of the rule steps applies to the approval request, c)determine a rule step order using the dynamic approval rule, d) executea first step of rule step order, the execution including delivery of theapproval interface to the approver, and c) receive an approval from theapprover.

Some embodiments of the invention include a dynamic approval systemcomprising a server connected to a computer network, and a databaseconfigured to operate on the server and to store a dynamic approval ruleincluding at least one rule step having rule step criteria fordetermining if the rule step is applicable to an approval. Theseembodiments also include a workflow approval builder including a userinterface configured to define the dynamic approval rule, the rule step,the rule step criteria, and values characterizing the rule stepcriteria; and an approval engine configured to load the dynamic approvalrule from the database, to process the dynamic approval rule todetermine at least one applicable rule step responsive to the rule stepcriteria, and to execute the applicable rule step.

Some embodiments of the invention include a dynamic approval rulebuilder comprising a rule design interface configured to receive inputfrom a designer, the input characterizing the dynamic approval ruleincluding a rule step for requesting approval from an approver, theinput being for determining if an identity of the approver is dependenton an identity of a requestor or is independent of the identity of therequestor, and a rule generator configured to produce data defining thedynamic approval rule responsive to the input.

Some embodiments of the invention include an approval engine comprisingan approval interface configured for presentation to a reviewer or anapprover, the approval interface including commands configured to addanother reviewer or another approver to a current approval process, andan approval rule processor configured to generate the approval interfaceresponsive to a dynamic approval rule having a rule step associated withthe reviewer or the approver.

Some embodiments of the invention include an approval engine comprisingan approval interface configured for presentation to a reviewer or anapprover, the approval interface including commands configured toapprove a subset of an approval request, and an approval rule processorconfigured to generate the approval interface responsive to a dynamicapproval rule having a rule step associated with the reviewer or theapprover.

Some embodiments of the invention include a method of creating anapproval rule, the method comprising a) presenting a rule designinterface to a designer, b) creating a dynamic approval rule using inputreceived through the rule design interface, c) creating a rule step forinclusion in the dynamic approval rule, the rule step being for sendingan approval request or a review request to an approver or a reviewerrespectively, d) defining rule step criteria characterizing conditionsrequired for the rule step to be executed in an approval process, and e)saving data defining the rule step.

Some embodiments of the invention include a method of generating anapproval responsive to an approval request, the method comprising a)executing an application including a business object operation, b)determining if the business object operation requires approval, c)executing an approval engine for processing a dynamic approval rule, thedynamic approval rule including a rule step and being assigned to thebusiness object, the rule step being executed responsive to an identityof the business object, and d) setting a parameter indicating if theapproval engine returns an approved or a denied status.

Some embodiments of the invention include a method of processing anapproval request, the method comprising a) loading at least one dynamicapproval rule including one or more rule steps characterized by rulestep criteria, b) determining if at least one of the rule steps appliesto the approval request c) determining a rule step order by processingthe dynamic approval rule, d) executing a first step of rule step order,the execution including delivery of an approval interface to anapprover, and e) receiving an approval from the approver.

Additional embodiments are disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a dynamic approval system according tovarious embodiments of the invention;

FIG. 2 is an illustration of a structure of a dynamic approval ruleincluded in an embodiment of the invention;

FIG. 3 is an illustration of a method of generating an approval ruleaccording to various embodiments of the invention;

FIG. 4 is an illustration of an embodiment of a rule design interface;

FIG. 5 is an illustration of an embodiment of a rule design interfaceconfigured to create a rule step;

FIG. 6 is an illustration of an embodiment of a rule design interfaceconfigured to create step criteria;

FIG. 7 is an illustration of an embodiment of a rule design interfaceconfigured to assign an approval rule to business object;

FIG. 8 is an illustration of a method of using a dynamic approval systemaccording to various embodiments of the invention;

FIG. 9 is an illustration of further details of an execute approvalengine step;

FIG. 10 is an illustration of an embodiment of an approval interfaceconfigured to convey an approval request to an approver; and

FIG. 11 is an illustration of an embodiment of an approval interfaceshowing the status of three approval rules.

DETAILED DESCRIPTION OF THE INVENTION

The invention includes a dynamic approval system intended to facilitatea wide variety of processes such as obtaining and tracking approvals. Incomparison with the prior art, the dynamic approval system is moreeasily configured and adapted to changing conditions and requirements.For example, embodiments of the invention may automatically adjust anapproval process responsive to a change in organizational structure orthe position and privileges of a user.

In various embodiments the dynamic approval system is configured forapplications in human resources, procurement, research and development,accounting, and the like. In addition, embodiments of the dynamicapproval system are configured to integrate directly into software, suchas network based enterprise applications, that facilitate the tasksrequiring approval. As a result of this integration, the same programsused to accomplish a task, such as buying an electronic part, may alsobe used to obtain proper approvals for the purchase. This integrationsimplifies the purchasing process and prevents errors since a purchaseorder can be prevented from issuing until all appropriate approvals aremeet. As illustrated further below, integration between the dynamicapproval system and network based enterprise software enablesintelligent management of the approval process.

The dynamic approval system of the present invention achieves itsflexibility and versatility through the use of dynamic approval rules. Adynamic approval rule is a rule for determining approval and/or reviewof some activity or request. One or more dynamic approval rules are usedin each approval process. Each dynamic approval rule includes at leastone rule step characterized by rule step criteria and optional rule stepcriteria values. In a typical example, a rule step is configured torequest approval from one person and the rule step is executed only ifthe associated rule step criteria are meet.

A dynamic approval rule is dynamic in that it is not necessarily “hardwired” in computer code or scripts. In contrast with the prior art, adynamic approval rule includes a step or steps that may changedynamically responsive to an identity of the approval requester, a classof the approval, costs, personnel availability, changes inorganizational structure, or the like. Dynamic approval rules may alsohave rule steps dynamically added or ignored during the performance ofan approval process.

FIG. 1 illustrates an embodiment of a dynamic approval system,designated 100, according to the invention. This embodiment includes aserver 110 typically connected to a computer network and configured tosupport a database 120. Database 120 is configured to store at leastdynamic approval rules and associated data. Data is stored in database120 by a workflow approval builder 130 and retrieved from database 120by an approval engine 140. Workflow approval builder 130 is used by adesigner of an approval process to generate dynamic approval rules. Inthis generation process a rule designer interface 150 is presented tothe designer for input characterizing a dynamic approval rule. Inresponse to input provided by the designer, a rule generator 160produces data defining one or more dynamic approval rules. This data istypically stored in database 120. Once defined, dynamic approval rulesare optionally assigned to specific business objects (e.g. softwareroutines designed to accomplish specific business tasks and optionallyassociated with departments such as sourcing, engineering, manufacturingdefinitions, production control, product configurations, qualitycontrol, accounting, sales, marketing, and the like), are passed asobjects to other routines or are further modified for specificapplications.

Approval engine 140 is configured to interpret dynamic approval rulesand request approvals accordingly. In a typical embodiment, approvalengine 140 includes an approval interface 170 for presentation to aparty whose approval is requested. The solicited party and the contentsof approval interface 170 are determined by an approval rule processor180 configured to process dynamic approval rules such as those generatedby workflow approval builder 130. Further details of methods used byworkflow approval builder 130 and approval engine 140 are describedbelow.

A dynamic approval rule typically includes at least one “rule step,”“rule step criteria” (or “criterion”) associated with each approval stepand one or more optional “criteria value” used to characterize the rulestep criteria. FIG. 2 illustrates the structure of one dynamic approvalrule included in an embodiment of the invention and generally designated200. Dynamic approval rule 200 is identified using rule ID 202 anddescription 204. Rule ID 202 is a unique identifier used duringassignment or access of dynamic approval rule 200. Every dynamicapproval rule, such as dynamic approval rule 200, includes at least onerule step 210A and optionally further rule steps 210 such as rule step210B.

Each rule step 210 typically includes a request for one approval fromone party. However, in some embodiments rule step 210 may includerequests for a list of related approvals. For example, in one of theseembodiments rule step 210 includes a request for approval of either anentire purchase order or alternatively requests for approval of severalline items within the purchase order. In other embodiments rule step 210includes a request for approval from a pooled list of possibleapprovers. In one of these embodiments rule step 210 is completed if onemember of the pooled list gives approval. In another of theseembodiments rule step 210 is completed only after all members of thepooled list give approval.

Rule step 210A is characterized by an “approver type” 212 and a“description” 214. Examples of approver type 212 include “approver” and“reviewer.” An approver is a party who is notified of a request andasked to approve or disapprove. A reviewer is a party who is notified ofa request but not asked to approve or disapprove. For example, aninstance of a rule step 210 may be used to notify a facilitiesdepartment of a request to purchase computer hardware without requiringthat the facilities department approve of the purchase.

Description 214 is used to establish the identity of the approver orreviewer. For example, in the embodiment illustrated by FIG. 2,description 214 is assigned the value “Supervisor” and the approver willtherefore be the supervisor of the requester. “Supervisor” is a relativedescription 214 because it determines the approver through a relativerelationship between the requestor and the approver. In order to resolverelative relationship embodiments of description 214, dynamic approvalsystem 100 (FIG. 1) uses an organizational chart, optionally stored indatabase 120. In other embodiments description 214 refers to a specificperson or a specific position in the business organization. For example,description 214 may be “William Smith” or “Chief Technology Officer”respectively. Using these descriptions 214 the approver is independentof the identity of the requestor.

Rule steps 210 are optionally executed in parallel or in series. Inembodiments wherein dynamic approval rule 200 includes more than twosteps various groups and subgroups of rule steps 210 are optionallyexecuted in serial and parallel combinations. Typically a rule steporder is initially determined during the development of dynamic approvalrule 200.

Each rule step is subject to one or more criteria. For example, rulestep 210A is only executed if criteria 220 are satisfied. In theembodiment illustrated by FIG. 2, criteria 220 includes “Value Type”221, “Record” 222, “Approval Field” 223, “Approval Record” 224, “AmountField” 225 and “Amount” 226. The determination of which criteria applyto a specific dynamic approval rule is optionally determined responsiveto a business object to which the rule is assigned. For example, apurchasing business object may have the Amount 226 parameter used toindicate a cost while an engineering business object may not have a costassociated with approval of a design and therefore not require theamount 226 parameter.

Approval field 223 is distinct in that it is evaluated using values 230,such as criteria values 230A and 230B associated with the step criteria220. In the example illustrated by FIG. 2, Approval Field 223 is set tothe type “Business_Unit” and therefore criteria values 230A and 230B areinterpreted as specifying that the business unit of the current businessobject must be within the ranges US001-US010 and US012-US100. If thiscondition, relating to approval field 223, is not satisfied then rulestep 210A does not apply to the current approval request and will not beexecuted.

In some embodiments rule step 210 is only executed when all of criteria220 are satisfied. If any of criteria 220 are not satisfied step 210 isskipped and the approval rule 200 proceeds to the next rule step 210. Inthese embodiments, in order for dynamic approval rule 200 to beconsidered in the approval process, at least one rule step 210 must meetall criteria 220. In alternative embodiments only one of the associatedcriteria 220 need be satisfied in order for a rule step 210 to qualifyfor execution.

In some embodiments of the invention, rule steps 210 may changedynamically during the processing of an approval request. For example,in one embodiment rule step 210 must be approved within a specific timeperiod. If an approver does not respond within this time period rulestep 210 is either skipped or directed to an alternative approver. In asimilar manner, a rule step 210 may automatically be skipped orredirected when an approver is on vacation or is otherwise no longeravailable.

An approver is optionally not permitted to approve their own requests.For example, in an embodiment where a hardware manager approves allcomputer hardware purchases, the hardware manager is not asked toapprove his own request, above a certain dollar limit, for a computer.In such a case the applicable rule step 210A is skipped or directed toan alternative approver.

In various embodiments of the invention the one or more steps 210 can beeliminated during an approval process. For example, if dynamic approvalrule 200 includes rule steps 210 that request approval from an immediatesupervisor and also from a higher level manager, the approval from thesupervisor may no longer be necessary once the manager has approved. Theunnecessary rule step associated with the supervisor is optionallyskipped and the approval process escalates to the next rule step. Ifapprovals are requested in parallel and the manager gives her approvalfirst then the request to the supervisor is optionally cancelled.Likewise, dynamic approval system 100 will notice if the manager'sapproval is required regardless of the supervisor's approval. In thesecases, since the supervisor's approval is superfluous, a rule step 210Arequesting approval from the supervisor may never be executed or,alternatively, the approver type of this rule step 210A may be changedfrom approver to reviewer.

In various embodiments of the invention rule steps 210 can be addedduring an approval process. Additions can be made by approvers orreviewers who wish to involve other “ad hoc” parties in an approvalprocess.

In one embodiment an order of rule steps 210 is changed by adding a newrule step 210 including an approver who was already associated with anexisting rule step 210 in the current approval rule 200. Since,typically, an approver need only give approval once during any givenapproval process, the second approval is redundant and is skipped bydynamic approval system 100. Because the new rule step 210 may be in adifferent position in the rule step order, the order of rule stepexecution may be changed.

Rule steps 210 can be generally categorized as “internal” or “external.”Internal rule steps, such as rule step 210A, are related to criteria 220developed using workflow approval builder 130. External rule steps donot necessarily depend exclusively on criteria 220 but alternativelyinclude links to external processes, data, and/or rules. For example, anexternal rule step may use an organization chart associated with aspecific project or ad hoc work group instead of a default businessorganizational chart. Since this data is external it can more easily bemaintained and modified by users who would normally not be permitted tochange the business organizational chart. Ad hoc work groups may also beorganized such that the business organizational chart would inadequatelyrepresent relationships within the group.

Dynamic approval rule 200 optionally includes rule steps 210 configuredto perform special functions. For example, a rule step 210 may be a“stop step” wherein approval or disapproval halts analysis of thecurrent approval rule or the entire approval process. In an illustrativeembodiment, wherein all hiring must be approved by the Vice President ofhuman resources, dynamic approval rule 200 would include a stop stepassociated with this Vice President. If she disapproves such a request,all other requests for approval from other approvers are cancelled. Inanother example of rule steps 210 configured to perform specialfunctions, “line item steps” may be configured to approve or disapprovespecific line items in an approval request.

FIG. 3 illustrates a method of generating a dynamic approval rule 200according to various embodiments of the invention. This method isoptionally performed using workflow approval builder 130. In a createapproval rule step 310 rule design interface 150 is used to enter datacharacterizing the desired dynamic approval rule. In this stepparameters applying to the entire dynamic approval rule are specified.For example, a rule ID, and description are assigned. Optionallyspecified are options for enabling escalation. Escalation is a processby which rule steps are skipped as a result of a time-out,unavailability of a reviewer, rule step redundancy or dynamic rule stepelimination. Escalation options include time-out periods and thedelivery of escalation event notices, among others.

Following create approval rule step 310 a rule step 210 is added to thenew dynamic approval rule 200. This rule step 210 is generated in acreate rule step in step 315 using rule design interface 150. In step315 parameters applicable to all of the new rule step 210 aredetermined. These parameters generally include a step number,description 214, approver type and step type (internal or external).

A query step 320 determines whether the new rule step 210 has beendefined as an external or an internal step. If it is external, then anassign external process step 325 is executed. In step 325 criteriaassigning an external process or data to the new rule step 210 isgenerated and saved in a step 355. Typically, an external step includesno further criteria. However, in alternative embodiments (not shown)additional criteria may be defined. If the new rule step 210 is notexternal, create step criteria step 330 is optionally performed tocreate criteria 220 for the new rule step 210. In create step criteriastep 330 criteria such as value type 221 (FIG. 2), approval field 223,and amount 226 are specified. In one instance, a monetary figure of 100is associated with amount 226 criteria. In this instance the associatedrule step 210 is only executed for requests involving more than 100 USdollars.

Create step criteria 330 is followed by an optional assign criteriavalue step 335. In step 335 a value 230 or value range is associatedwith the criteria established in create step criteria step 330. In someembodiments this value 230 or value range is applicable only to theapproval filed 223 criteria. If, in a query step 340 it is determinedthat further criteria values 230 are desired, then assign criteria valuestep 335 is repeated. Likewise, if in query step 345 it is determinedthat further criteria 220 are required for the new rule step 210, thenthe method may return to create step criteria step 330. Finally,following query step 350 in which the a desire for additional rule steps210 is determined, the method either returns to create rule step 315,for adding another rule step 210 to dynamic approval rule 200, oralternatively performs save step 355 to store generated rule data indatabase 120 (FIG. 1). After the generated rule data is saved the newlygenerated dynamic approval rule 200 is optionally assigned to a businessobject in an assign step 360.

FIG. 4 illustrates an embodiment of rule design interface 150 used toperform create approval rule step 310 of FIG. 3. This embodimentincludes fields for entering Rule ID 202, rule type 410 and description204. Rule type 410 is used to specify a dynamic approval rule 200 asincluding “static” or “dynamic” rule steps 210. Also included arecheckboxes for enabling escalation 430 and specifying escalation options440. The hyperlink “Go to Steps for this Rule” 450 is used to executecreate rule step in step 315 of FIG. 3.

FIG. 5 illustrates an embodiment of rule design interface 150 configuredto perform create rule step in step 315 of FIG. 3. This embodimentincludes a first data entry table 510 used to enter data such as stepnumber 511, description 214 and approver type 212. A self approval table520 is configured to indicate a specific amount 522 authorized for selfapproval. Finally, a fulfill criteria table 530 is optionally used toestablish criteria logic and to initiate create criteria associated withthe new rule step 210.

FIG. 6 illustrates an embodiment of rule design interface 150 configuredto perform create step criteria step 330 of FIG. 3. In this embodiment adata entry table 610 is used to enter data, such as an amount 620 of100.000. In this instance the associated rule step 210 is only executedfor requests involving more than 100 US dollars. A value type table 630is used to set value logic or access another embodiment of designinterface 150 for setting values associated with approval field 640.

FIG. 7 illustrates an embodiment of rule design interface 150 configuredto assign approval rules to business objects as in assign step 360. Twocheckboxes 710 are used to indicate if assigned rules are to be used forworkflow approval or schedule approval. Rules to be assigned areindicated by their Rule ID 202 in a table 720. A second column 730, intable 720, is used to indicate the order of dynamic approval rule 200priority. A given dynamic approval rule 200 may be the prior rule formore than one other dynamic approval rule 200. This allows both serialand parallel ordering of approval rule consideration. A third column 740is used to indicate if a dynamic approval rule 200 is a stop rule. Thenumber of rules indicated in FIG. 7 is an illustrative example. Businessobjects may be assigned none, one, or a plurality of rules.

FIG. 8 illustrates a method of using dynamic approval system 100according to various embodiments of the invention. In a run businessobject step 810 a business object is executed. The business object isoptionally part of an enterprise application which is optionally aninternet application configured to operate using HTML/Java basedinterfaces. In a typical example the business object is used to make arequest, such as approval of an engineering drawing. Depending on thenature of the request, a developer of the business object may havepreviously indicated that approval for the request is needed. If so,this requirement is determined in query step 815. If approval is notneeded no further action is taken and the business object continuesexecution without interruption. However, if approval is required,approval engine 140 is executed in an execute approval engine step 820to process dynamic approval rules 200 assigned to the business object.Execute approval engine step 820 is optionally performed using approvalrule processor 180 and results in setting of a parameter indicatingwhether the request was approved, denied, or otherwise qualified.Further details of step 820 are illustrated in FIG. 9 below. Followingexecute approval engine step 820, a query step 825 examines whether therequest has been approved. If so, then an optional approval notice step830 is used to notify the requester, and optionally other partiesinvolved in the request, of the approval. If not, then an optionaldenial notice step 835 is used to notify the requester, and optionallyother parties involved in the transaction, of the denial. Finally, themethod optionally returns to step 810 wherein the business objectcontinues execution.

FIG. 9 illustrates further details of execute approval engine step 820.In the illustrated embodiment execute approval engine step 820 beginswith a load approval rule step 910 where one or more dynamic approvalrules 200 assigned to the current business object are loaded fromdatabase 120. In a parse approval rules step 915 applicability of theloaded rules 200 to the current approval request is examined. Thisexamination includes comparison of each rule step 210 and associatedcriteria 220 with characteristics of the approval request. For example,a business unit associated with the current business object may becompared with criteria 220 specifying that a rule step 210 applies onlyto certain business units. In another example, the value of the currentapproval request is compared with an amount 226 (FIG. 2). Theapplicability of each rule step 210 within the loaded dynamic approvalrules 200 is determined based on these and similar comparisons. At leastone rule step 210 within a dynamic approval rule 200 must have criteria220 that is satisfied for the particular dynamic approval rule 200 to beconsidered further in the current approval request. A query step 920 isused determined if parse approval rule step 915 has found that any ofthe loaded dynamic approval rules 200 apply to the current request. Ifnot, a value indicating that no approval is needed is set in a setparameter step 925 and the instance of execute approval engine step 820is completed.

If at least one dynamic approval rule 200 is found to apply to thecurrent approval request, the method continues to a process rules step930. In process rules step 930 at least one step order of applicablerule steps 210 is determined. This step order may include both serialand parallel sequences. Rule steps 210 from different approval rules 200are optionally interspersed in a single step order. In some embodimentsdifferent dynamic approval rules 200 are used to generate separate rulestep orders that are independently processed sequentially or inparallel. In some embodiments rule steps 210 that require a responsefrom the same approver are combined to reduce the number of requeststhat each approver must respond to. For example, if one rule step 210requires a response from the requestor's supervisor and another rulestep 210 requires a response from the chief product engineer, these mayboth be the same person. In this case, both of these rules steps 210 arecombined into a single rule step 210 for the purposes of the currentapproval request. Rule steps 210 may be combined from within the sameapproval rule 200 or from separate dynamic approval rules 200.

After a step order is determined the method proceeds to a make requeststep 935 where the first rule step 210 of a current step order isperformed. In embodiments having parallel sequences make request step935 may include performing several rule steps 210. The performance of arule step 210 includes delivery of a request to a reviewer or approverand, if necessary, waiting for an approval. In various embodimentsperformance of a make request step 935 also includes monitoring of“time-out” status for pending requests, adjustment of the step orderresponsive to the introduction of ad hoc steps, or the like.

After a response is received from an approver, or a time-out occurs, aquery step 940 examines if approval has been received. If not, therequestor is notified in a notify step 945. In some embodiments notifystep 945 is followed by a query step 950 that examines if the denial ofapproval applied to the entire approval request or a subset of theapproval request. If approval of suborders (e.g. line items) is stillpossible, the method continues with a suborder approval step 955. Insuborder approval step 955 the non-approved items within the order aremarked as not approved. The method then continues to a query step 975for determining if rule steps 210 remain to be executed. If in querystep 950 it is determined that no approval of suborders is possible avalue indicating this result is set in a set parameter step 960 and theinstance of execute approval engine step 820 is completed.

If, in query step 940, approval has been received, the method optionallycontinues to a query step 960 in which it is determined if the approvedrule step 210 is a stop step that would indicate that the currentdynamic approval rule 200 is satisfied. If the approved rule step 210 isa stop step then a query step 965 is optionally executed to examine theexistence of additional applicable dynamic approval rules 200.

If, in query step 960, the approved rule step 210 is found not to be astop step the method continues to a query step 970 in which the presenceof any new rules steps 210, added during make request step 935, isdetermined. If new rule steps 210 have been added, then the methodreturns to make request step 935 wherein the next rule step 210 in therule step order is processed. If a new rule step 210 has not been added,the method continues to a query step 975 wherein the presence of furtherrules steps 210 in the step order is examined. If a further rule step210 is to be processed, the method returns to make request step 935. Ifno further rule steps 210 are pending in the current rule step order themethod optionally proceeds to query step 965. If, in query step 965, itis determined that additional approval rules are to be executed, thenthe method returns to make request step 935 wherein the next rule steporder is processed.

If no additional approval rules are to be executed the method continuesfrom query step 965 to set a parameter step 980. Set parameter step 980waits until all parallel executions of steps 935 through 965 arecompleted with approvals. If all approvals are received, set parameterstep 980 includes setting a value indicating that approval has beenreceived for the requested task and execute approval engine step 820 iscomplete.

FIG. 10 illustrates an embodiment of approval interface 170 configuredto convey an approval request to an approver in make request step 935.This embodiment of approval interface 170 includes “approve” 1010,“deny” 1020 and “hold” 1030 buttons for indicating the approver'schoice. A row 1040 optionally includes commands configured to add an adhoc reviewer or approver to the current approval process. Addition of anad hoc reviewer or approver results in a new rule step 210 being addedto the current approval process. A region 1050 optionally shows to anapprover a current status of the approval request. Region 1050 may showrule steps 210 executed both in series and in parallel. This embodimentof approval interface 170 is optionally configured for presentationusing a browser supporting only standard HTML/Java script protocols.

As illustrated in FIG. 11 the status of an approval process may beviewed by a requestor or other interested party. FIG. 11 illustrates anembodiment of a status interface 1170 showing the status of threedynamic approval rules 200 (“Dynamic Role Query” 1102, “Level 1Commodity Approval” 1103 and “Level 2 Commodity Approval” 1104). Thisembodiment of status interface 1170 shows that status of an approvalrequest having rule steps 210 executed both in series and in parallel.Also in this example, two of the dynamic approval rules 200 include oneapprover, Wendy Cho 1110, in common. In some embodiments this approverwould receive one request for approval that would satisfy both dynamicapproval rules 1102 and 1103.

Several embodiments are specifically illustrated and/or describedherein. However, it will be appreciated that modifications andvariations are covered by the above teachings and within the scope ofthe appended claims without departing from the spirit and intended scopethereof. For example, the present invention may be applied to reviewingas well as approval processes and is not limited to the applications orbusiness objects used herein as illustrative examples. In many of theexamples discussed, a reviewer may be substituted for an approver.Likewise, use of an “organizational chart” or “business organizationalchart” to determine relationships between parties is meant to encompassuse of any data identifying relationships between members of anorganization. It is anticipated that the systems and methods disclosedherein may be applied to other activities requiring discrete sequentialsteps such as project scheduling and tracking.

What is claimed is:
 1. A dynamic approval rule builder comprising: arule design interface configured to receive input from a designer, theinput characterizing the dynamic approval rule including a rule step forrequesting approval from an approver, the input being for determining ifan identity of the approver is dependent on an identity of a requestoror is independent of the identity of the requestor; and a rule generatorconfigured to produce data defining the dynamic approval rule responsiveto the input.
 2. The dynamic approval rule builder of claim 1, furtherincluding a server configured to store the data defining the dynamicapproval rule.
 3. The dynamic approval rule builder of claim 1, whereinthe rule step includes step criteria for determining if the rule step isapplicable to an approval request.
 4. A method of creating an approvalrule, the method comprising: presenting a rule design interface to adesigner; creating a dynamic approval rule using input received throughthe rule design interface; creating a rule step for inclusion in thedynamic approval rule, the rule step being for sending an approvalrequest or a review request to an approver or a reviewer respectively;defining rule step criteria characterizing conditions required for therule step to be executed in an approval process; and saving datadefining the rule step.
 5. The method of claim 4, further includingassociating the rule step with an approver using a relativerelationship.
 6. The method of claim 4, further including assigning anexternal process to the rule step.
 7. The method of claim 4, furtherincluding assigning the rule step to a business object.
 8. The method ofclaim 4, further including creating a second rule step for inclusion inthe dynamic approval rule.
 9. An approval engine comprising: an approvalinterface configured for presentation to a reviewer or an approver, theapproval interface including commands configured to add another revieweror another approver to a current approval process; and an approval ruleprocessor configured to generate the approval interface responsive to adynamic approval rule having a rule step associated with the reviewer orthe approver.
 10. The approval engine of claim 9, wherein the approvalinterface is based on HTML/Java script protocols.
 11. The approvalengine of claim 9, wherein the dynamic approval rule includes aplurality of rule steps executed in serial and parallel combinations.12. The approval engine of claim 9, wherein an order of rule stepexecution is responsive to the addition of another reviewer or anotherapprover.
 13. The approval engine of claim 9, wherein the approvalinterface further includes commands configured to approve a subset ofthe approval request.
 14. The approval engine of claim 9, wherein theassociation with the reviewer or the approver is a relativerelationship.
 15. The approval engine of claim 9, wherein the rule stepis a stop step.
 16. The approval engine of claim 9, wherein the approvalrule processor is further configured to consider a plurality of dynamicapproval rules to process an approval request.
 17. The approval engineof claim 9, wherein the approval rule processor is further configured tocombine two rule steps, requiring response from the same approver, intoa single rule step.